home *** CD-ROM | disk | FTP | other *** search
/ Shareware Overload Trio 2 / Shareware Overload Trio Volume 2 (Chestnut CD-ROM).ISO / dir24 / aprs60.zip / OPS.TXT < prev    next >
Text File  |  1994-09-28  |  22KB  |  338 lines

  1. OPS.txt 6.0                APRS OPERATIONS NOTES
  2.  
  3. Version 6.0:  See the alt-IGNORE command description under the SPECIAL EVENT
  4. section below.  It allows special events to IGNORE all other APRS traffic on
  5. frequency to keep their screens clear for the special event stations only.
  6.  
  7.  
  8.    This OPERATIONS file may help you to understand the finer points of
  9. operating an APRS net.  It covers the two categories of operations.  ROUTINE
  10. and SPECIAL EVENT.  Also read the section on OBJECTS since the information
  11. there applies to both cases.  Since APRS was designed to facilitate real-
  12. time tactical communications, operating APRS on a routine basis is sometimes
  13. about as exciting as watching the grass grow!  The reason for building a
  14. routine APRS net is primarily for operator training and familiarity.  If your
  15. operators are not familiar with APRS in a benign environment, then they will
  16. not be able to use it in a crisis! 
  17.  
  18.      APRS has a very powerful BULLETIN feature permitting stations to post
  19. multiple-line BULLETINS to all stations.  This is very importnat to "get the
  20. word out" to all stations in a net, either routine, or special event.  Also,
  21. do NOT think that you need GPS for tracking special events.  With version 5.7,
  22. it is so easy to update your vehicle's position just by moving the cursor
  23. and hitting the INPUT MyPOS command (I M)., that the only stations that need
  24. GPS are the ones that are lost! 
  25.  
  26. BULLETINS:  To send a bulletin to all stations, simply use the normal SEND
  27. command, but instead of a callsign, Send the message to BLN# where # is the
  28. line number of your multiple line Bulletin.  APRS stations will grab these
  29. messages addressed to BLN# and sort them onto the BULLETIN page.  Like any
  30. other message, these BULLETIN lines will be transmitted on the decaying time
  31. period and will eventaully settle out at once every 15 minutes.  This way,
  32. new stations joining the net will quickly pick up the BULLETINS.  Since lines
  33. are sorted onto the BULLETIN page, a new BLNx line will overwrite the BLNx on
  34. line at all stations so that corrections can be made at any time.  If your
  35. bulletin is time sensitive, be sure to include the TIME in the text, since
  36. BULLETINS are not time-stamped on receipt.  When your BULLETIN is no longer
  37. needed, simply ERASE the outgoing BLN# message lines.  This will stop your
  38. transmitting of the BULLETIN lines, but they will remain on everyone's screen
  39. that heard them.  To erase them on everyone's screen, replace them with
  40. somthing new, or send a BLN# with a few blank spaces to overwrite the old
  41. lines.  With this new bulletin feature, it should be much easier to
  42. keep all stations posted on local APRS events...
  43.  
  44.  
  45. GATEWAY RULES:  I have interjected this paragraph because of the large number
  46. of APRS HF to VHF gateways now in operation.  First, it is very important that
  47. users understand that GATEWAYS ARE ONLY INTENDED TO LINK HF ACTIVITY INTO
  48. LOCAL VHF NETS.  IT IS INNEFFICIENT, DISCOURTEOUS, AND OFTEN ILLEGAL TO LINK
  49. from VHF to HF.  The illegality comes about if the GATEWAY is unattended.
  50. With current hardware, a gateway sysop cannot selectively restrict the VHF
  51. input, so it is incumbent on users to respect this deficiency and NOT put the
  52. sysop of the gateway at risk.  Linking HF operations into every local VHF
  53. APRS net in the country is not a problem, because the slow 300 baud data rate
  54. could never saturate ANY 1200 baud local net.  HOWEVER, linking just ONE
  55. active VHF net ANYWHERE in the country out onto HF WOULD CERTAINLY 100% BLOCK
  56. ALL HF OPERATIONS NATIONWIDE!  The capability is there for linking special
  57. events on VHF out for the entertainment of all HF listeners, but DO NOT ABUSE
  58. IT, OR WE WILL LOOSE IT!  See HF.txt for suggested frequencies.
  59.  
  60.  
  61. DIGIPEATER RULES:  The advantages of APRS are many, but there is a price.
  62. Since APRS uses a fixed digipeater path sometimes different for different
  63. stations depending on geographic location, there is a duplication of on the
  64. air packets.  This assures that all stations in the net are maintained up to
  65. date, but also proves to be less efficient during intense operator-to-operator
  66. QSO's where this point-to-point traffic is still being unnecessarily broadcast
  67. to all stations in the net.  For this reason, APRS operators should consider
  68. using TNC TALK mode (connected) to do intense one-on-one keyboard QSO's.
  69. Especially if a direct connect without using APRS digipeaters is possible!
  70. See MARATHON.txt for lessons learned at the Marine Corps Marathon (1993) and
  71. the many imporvements to APRS that resulted!
  72.  
  73.  
  74. ACKS THAT DONT MAKE IT:  Just like connected packet, the chance of a message
  75. packet getting through is usually the same as the chance that the ACK will
  76. get back.  If the radio path is only giving a 50% chance of a packet getting
  77. through, that means that the receiver will probably get the message by the
  78. second transmission, but that the sender may not get an ACK until after his
  79. fourth transmission!  This is because the sender had to send 4 packets to get
  80. two through and the receiver then ACKed twice in order to get one through.
  81. You see this effect frequently on APRS, when you are communicating with a
  82. station over a long poor path.  You will notice that the person at the other
  83. end has already responded to your message even before you get an ack.  BUT
  84. your next line will never go out UNTIL it gets that ACK.  The reason that
  85. you will probably get his response message before your ack, is because his
  86. response message is being repeated over and over in the usual APRS decayed
  87. algorithm, but his ACK is ONLY transmitted once each time he gets a dupe of
  88. your message line to him.
  89.  
  90.     What this means is that whenever it is obvious that the other station has
  91. responded to your message line, you should ERASE it so that APRS will move on
  92. to the next line.  Sometimes if you know that the other station is probably
  93. hearing the digi better than the digi is hearing him, and you are not getting
  94. ACKS, then simply send him messages in the blind.  Let each line be transmitted
  95. for 6 minutes and then erase it.  APRS will then move on to the next line.
  96. Remember that APRS will have transmitted 6 times in the first 6 minutes, but
  97. that it will then be over 3 minutes, then 6 and then 12 minutes for further
  98. transmissions.
  99.  
  100.     Watching this effect of lost ACK responses on HF this summer between the
  101. 25 Naval Academy boats running APRS on HF, I made a significant change in
  102. APRS503a.  Now, when APRS recognizes a duplicate message, it sends out the
  103. usual ACK, but stores a copy for transmisssion in the blind 30 seconds later.
  104. The reason for the 30 second delay is to avoid cluttering up the frequency
  105. if the path is good, since the sending station will have sent the message
  106. at least twice in the first 30 seconds.  After the third transmission, it is
  107. clear that the ACKs were lost and it is time to double up.  This simple
  108. change to the ACKING process has the potential of doubling throughput on a
  109. poor channel!
  110.  
  111.  
  112. SHORT MESSAGES:  As with any packet, especially on HF, the shorter the packet
  113. the better the chance of getting through.  Since a packet often has about
  114. 25 characters of overhead, however, there is not much sense of making the
  115. message part much shorter than a half line (40 characters).  The chance of
  116. a 40 character line getting clobbered compared to a 75 character line is
  117. 65%.  On HF (under poor conditions), keep 'em short.  A neat trick that I
  118. frequently use whenever I know that a station is not currently on the air, or
  119. the path is not currently good, is to send the first message line with only
  120. the word "stby".  THen I type my lengthy several line message and walk
  121. away.  This way, only the very short "stby" line is transmitted (often
  122. for hours on HF) until the band opens, and then once the station ACKs that
  123. line, my remaining lines are transmitted.
  124.  
  125.      One last suggestion on HF and other poor paths that will make messages
  126. more sensible to the receiving station is to indicate to the receiver of a
  127. multiple line message that there are more lines to follow.  I use the >
  128. character to indicate that there is more to follow.  Without this, and by
  129. sending short lines, often it is not clear to the receiver that more is
  130. comming.  Often he tries to respond to my half sentences and then we spend
  131. twice as much time clarifying what in the world I am trying to say!  Another
  132. way to do it if you know how many lines you will be sending about the same
  133. subject is to indicate what line number it is out of the total.  For example,
  134. in a four line message, end the each line with >1/4, >2/4, >3/4, .4/4.
  135.  
  136.  
  137. ROUTINE OPERATIONS:  The APRS default digipeater path of RELAY is ok for a few
  138. users starting up an APRS net, but you will soon need to focus on a few good
  139. stations to serve as WIDE area digipeaters.  The reason for this is obvious.
  140. As soon as you get 3 or more local stations on APRS, any station living equi-
  141. distant (RF wise) from two other stations will ALWAYS hear a collision of
  142. EVERY packet digipeated by both of those stations.  That is why, once your
  143. network begins to grow, you need to designate your path by specific callsign
  144. and designate certain high stations as permanent digipeaters.  If you put up
  145. a few good wide area digipeaters with the generic ALIAS of WIDE, the coverage
  146. of the network can be extended significantly.  It is important to keep generic
  147. WIDEs well separated (40 miles or more over smooth terrain) to minimize
  148. duplicate repeats (or you end up with the same collison problem but on a larger
  149. scale).  Most users should be able to hit at least one of these WIDEs.  Just
  150. like with the RELAY's, however, users should use the specific digipeater call
  151. instead of the generic WIDE in routine cases to minimize collisions. In version
  152. 5.7 APRS permits the user to store up to 13 different, frequently used DIGI
  153. paths for instant recall.  THis way, the operator can tailor his DIGI path for
  154. the exact calls and path for each QSO.  Proper use of this capability can
  155. significantly improve APRS effeciency and reduce the use of the WIDE,WIDE
  156. generic path!
  157.  
  158.    All users must understand that they are responsible for setting their
  159. outgoing VIA path so that their packets hit the intended area of interest.
  160. Unlike normal CONNECTED protocols which automatically return ACKS via the
  161. reverse path of incomming packets, APRS is an unconnected broadcast protocol
  162. only and each station's packets will only go via the outgoing path set up by
  163. that station.  If your station receives a duplicate APRS MSG packet more than
  164. twice, it gives you a beep and an alert that your ACK's are probably not being
  165. heard by the other station and that you should check your outgoing VIA path.
  166.  
  167.  
  168.     APRS has a very useful feature for determining the best path between
  169. stations.  The Power-Height-Gain reporting capability lets APRS plot range
  170. contours around all stations that have included the P-H-G data in their
  171. position reports.  For maximum effectiveness, every station should use the
  172. INPUT-PWR command to enter his transmitter power, antenna height, and antenna
  173. gain.  Also APRS permanent digipeaters should include this info in their
  174. position beacons.  See DIGIPTR.txt for the exact formats.
  175.  
  176.     Those stations between WIDE area digipeaters only need to use the single
  177. hop of WIDE and their packets will go in both directions.  Stations that can
  178. only hit one WIDE area station may set the path of WIDE,WIDE without any
  179. conflicts.  Paths of WIDE,WIDE,WIDE should be avoided for routine operations
  180. because it folds back on itself.  The same area can be covered by using
  181. WIDE,WIDE,W3XYZ where the unique call of the third digipeater is specifically
  182. specified.  If you think about it, stations at the end of an area can specify
  183. a pretty long string of digipeaters since the path is linear.  Stations in
  184. the middle can only specify a symetrical double hop with WIDE,WIDE before
  185. they have to begin favoring one direction or another with unique calls.
  186.  
  187. CAUTIONS ABOUT APRS MESSAGES:  Remember that the general condemnation of
  188. multiple digipeater hops in the packet community applies only to connected
  189. protocols.  This is because the probability of success goes down drastically
  190. because all ACKS must be successfully returned or all packets are repeated.
  191. This is generally NOT a problem with most APRS operations since only UI frames
  192. are used, and there are no acks.  HOWEVER, APRS one-line MSGS are ACKED, and
  193. the inefficiency of digipeaters DOES APPLY!  If you do a lot of one-line
  194. messages between operators, you will experience the same hopeless probabilities
  195. of success as with conventional packet.  (As noted above, in version 503a,
  196. APRS doubles up on ACKS on a poor channel and helps this situation somewhat.)
  197. But, in general, NEVER expect an APRS MSG to be successful beyond 2 digi's
  198. except if everyone else is DEAD.  Operator messages are a secondary function
  199. of APRS, and should not be used as a primary means of passing traffic!  One
  200. further caution, since APRS suspends all packet processing while waiting for
  201. the operator with a BLUE-BOXED prompt, never linger in a blue-box prompt.
  202. The SEND command is a BLUE-BOXED prompt and should not be left un-completed!
  203.  
  204. OBJECTS:  As noted previously, anyone may place an object on the map and all
  205. other stations will see it.  In their systems, on their P-list, the object's
  206. position report will be marked with the last three letters of the station
  207. that is currently uplinking that position to the net.  A neat feature of APRS
  208. is that any station that has more current information on the location of that
  209. object can update its position by hooking, moving the cursor, and then
  210. hitting the insert key.  Now this new station begins uplinking the new posit,
  211. and all stations, will update their P-list entry for that object INCLUDING
  212. THE ORIGINAL UPLINK STATION!  The new position overwrites the old one so that
  213. the original station will now no longer uplink it.  This came in handy during
  214. hurricane tracking.  Who ever had information on the latest NWS EMILY
  215. position, uplinked it and everyone then always saw the latest storm track
  216. without anyone in the net being dependent on any one station for updates!
  217.  
  218.      Once objects are transmitted on to other station map screens, they will
  219. remain there until that operator deletes them.  Even if the original station
  220. stops sending the object position, it will remain there forever.  Once the
  221. object or station has not been heard from for 2 hours, it will fade to gray
  222. so that you know it is an old contact.  In version 4.01 a feature was added
  223. so that you can suppress the callsigns of old contacts.  Just press the J
  224. command, and select LATEST instead of selecting any specific object type.
  225. The result will be to redraw the map showing ALL symbols, but only the calls
  226. of the recent ACITVE stations less than 2 hours old.   Another feature added
  227. recently is the KILL function.  This permits the uplinker of an OBJECT to
  228. KILL it from all displays on the net.  His station will continue to uplink the
  229. object, but tagged with a special KILL flag to suppress its display on all
  230. screens.  It remains in everyone's P-lists, though, so they can refer back to
  231. it if needed.  They must still manually DELete it from their P-list as needed.
  232. Once the originator has KILLED an object, he should let it remain on his P-list
  233. for at least 4 minutes to be sure everyone has received the KILL indicator;
  234. then he can delete it from his list.
  235.  
  236.  
  237. SPECIAL EVENT OPERATIONS
  238.  
  239. Version 6.0:  In preparation for the MC Marathon 1994, I have added a very
  240. important feature.  The alt-IGNORE command sets up an APRS station to send
  241. all packets via the UNPROTO address of SPCL... vice APRS...  It also sets up
  242. that station to IGNORE all other packets.  This allows the event participants
  243. to keep their screens (P/L lists, etc) clear of unwanted other APRS stations
  244. on frequency, while tracking the event normally.
  245.  
  246. To keep this from preventing other NON-participating stations from seeing the
  247. packets, I have also added SPCL to the normal list of packets that APRS DOES
  248. monitor.  This means that APRS stations with version 6.0 (or who put OTHER on)
  249. WILL still receive all SPCL event posits on their screens, and they will be
  250. automatically marked with the # for special display.  This means a NON-
  251. participating station can still see just the SPCL stations by pressing the #
  252. key, instead of the SPACE bar.
  253.  
  254. SPECIAL EVENTS:  Let me use the Cycle Across Maryland (CAM) bike tour as an
  255. example of a special event which took a lot of daily APRS coordination.  We
  256. had two of three relief vehicles configured with GPS packet transponders.
  257. These were assembled in cake pan enclosures for duct-taping to the roof of
  258. any vehicle.  The uside down cake pans are reasonably aerodynamic and support
  259. both the GPS antenna and a 19 inch 2 meter whip.  A single power cable
  260. extended down the windshield and was clipped directly to the vehicle battery.
  261. The package could be moved to another vehicle in about five minutes.  The
  262. cake pan included only a walkie talkie transmitter at about the one watt
  263. level.  Other packet mobiles running APRS did not even need their GPS units
  264. since with the map on their laptop, they can just use the INPUT-MyPOS command
  265. at any time to update their positions to the network.  In this manner, my
  266. normal APRS/GPS combo can be split into TWO separate tracked vehicles for an
  267. event.  THe GPS/TNC combo as a stand-alone tracker, and my laptop and another
  268. TNC only for showing people where I am.
  269.  
  270.     Since we only have two WIDE area APRS digipeaters in the state, and the
  271. CAM tour never went near them, we were dependent on home stations all across
  272. the state to serve as digipeaters for the event.  The GPS packages were set
  273. to digipeat via the WIDE,WIDE path.  By setting the alias of all home
  274. stations along the route to be WIDE, the vehicles were never beyond range of
  275. at least one WIDE station.  Since the outgoing GPS packets were set up for
  276. WIDE,WIDE, the second digipeat was always picked up by one of the existing
  277. permanent WIDE digipeaters so that stations throughout the state could see
  278. the position of the one watt GPS units!  We were looking for home stations
  279. about every 10 miles.  Of course, as soon as a station was passed and was no
  280. longer in direct contact with the GPS units, it was IMPORTANT to remove the
  281. WIDE alias to minimize duplicative repeats.  For this seven day event, home
  282. stations were organized on a nightly basis.  Assigned stations would be WIDE
  283. for a whole day so that operators did not have to be home during working
  284. hours.
  285.  
  286.      As an added technique, we also set up both GPS units with the alias
  287. of WIDE so that they would also help digipreat each other along the trail.
  288. The disdavantage of this technique was evident as both vehicles returned to
  289. the evenings command post (also WIDE) and you had three WIDE digipeaters in
  290. 100 yards of each other!  It was noisy within local simplex range of that
  291. site, but stations all over the state still saw the packets via the permanent
  292. WIDE digipeaters.  Eighty percent of the home stations used as WIDE
  293. digipeaters had never even heard of APRS.  They simply heard about the need
  294. for home packet stations and only had to change their ALIAS (and frequency)
  295. as directed by local announcements posted on all area BBS's.
  296.  
  297.      The event was an exciting success!  Occasionaly there were not enough
  298. HAM voice operators per day to have HAMS in all of the relief vehicles.  When
  299. ever a shortage occurred, the HAMS were removed from the GPS vehicles and
  300. assigned elsewhere.  The location of the GPS vehicles were always known by
  301. net control via the APRS system so the need for a HAM rider was not necessary
  302. and in fact, only took up valuable space.  Whenever voice communications were
  303. needed with the GPS relief vehicle, a mobile HAM was directed to the location
  304. indicated on the APRS screen.
  305.  
  306. SYMBOLS:  During the 94 MS Bikethon in Northern Virginia, KD4SJJ noticed that
  307. with four GPS mobiles and several fixed stations along the route, that there
  308. were so many callsigns that you could not see the map.  He suggested making
  309. several numbered symbols so that all stations could be distinguished even
  310. with CALLSIGNS off!  This was such a good idea, that not only did we make
  311. lettered balls (A-J) for the mobiles, but we also made square boxes 0-9 for
  312. the fixed stations!  With these tactical symbols, and callsigns off, the map
  313. display is improved by an order of magnitude.  Also added in 5.03a were an
  314. additional 7 different mobile symbols for various vehicle types!
  315.  
  316. EMISSION CONTROL:  If there are only a few APRS stations involved in an event
  317. but there are lots of APRS observers on frequency, then the observers can set
  318. their transmitter off using the CONTROLS-X command.  That way they minimize
  319. QRM on channel.  While the transmit function is disabled, a one-time
  320. transmission can be forced each time the X key is pressed.  The X key
  321. enables one cycle of APRS transmission which may contain up to four packets
  322. containing your Beacon, Position, Objects, or Messages.  You can send only
  323. your MESSAGES by simply hitting the T (TRAFFIC) key once.
  324.  
  325. LOAD SHARING:  Since any station can take over reporting of any objects, one
  326. approach is to let only one station hook every symbol that comes in and then
  327. he becomes the reporting repsonsibility.  The original station that uplinked
  328. the report in the first place will fall silent when it sees the report
  329. comming from the designated Net Control station.  This way all positions are
  330. reported by only one station on frequency, although all other stations can
  331. still update the positions as needed.  Remember that the last station to
  332. report the position of an object will be the one that continues to report it!
  333.  
  334.  
  335. MARINE CORPS MARATHON:  See the MARATHON.txt for details and lessons learned
  336. using APRS at the Marine Corps Marathon on 24 October in Washington DC.
  337.  
  338.